﻿Writing a very simple game 




It is usually best to keep a couple of locations at the beginning in reserve, so although locations 0 and 1  must be listed in the location table, we will actually start with location 2, and we will have just 7 locations for our example game:
        
2.        At The Bus Stop
3.        On The Grass
4.        By The Bench
5.        The Bandstand
6.        The Ornamental Pond
7.        By The Tree
8.        Up The Tree


You will find the location descriptions in the file called game3.txt. You can enter the descriptions in the location text file, (/LTX) but I prefer to use just headers and set the descriptions in Process Table 1, as messages, which gives far more flexibility about what the descriptions actually say, as and when things change in the game world and avoid lots of untidy additions after the main description.  It doesn’t involve a lot of extra typing either, as you can just copy and paste all the text that is the same, and just make amendments where necessary.


The next step is to enter all the available exits in the connections table, /CON, which is in the same file, game3.txt.  Here you can only add exits that are freely available from the start.  Anything like locked doors etc need to be dealt with separately in process table 0.


Next we will enter the objects we wish to have in our game.  This table (/OTX) is also in the file game3.txt.  Object 0 is usually reserved for a light source, so Object 0 must be included even if there is no object there.


Lastly we need to add the objects to the object attributes table (/OBJ), also in game3.txt  there are several things we need to tell ACE about the various objects in the game, so we will start with where they are placed at the start of the game:


Object 1 at loc 2                #        The bag starts off at the bus stop
Object 2 at loc 254        #        The player is carrying the sandwich
Object 3 at loc 254        #        And the apple
Object 4 at loc _                #        The ticket is not created until the
                                        player climbs the tree and scares
                                        the bird away
Object 5 at loc 3                #        The lead is on the grass
Object 6 at loc 253        #        The player is wearing the jacket


In the same table, we now need to add additional attributes to the jacket (as it is being worn and therefore is wearable and removable) and the bag (as it is a container), and add weights for them if you wish.


You will now see why a couple of locations were reserved at the beginning.  If you have an object that is a container, you need to have a location in which to ‘store’ objects placed there.  You can of course use any location number you wish but I have found it easier if you use the location number that is the same as the object number.  In the example game, the bag is a container and is object number 1, and in this instance when the player ‘puts’ something in the bag, that something is moved to location 1 until such time as it is brought out again.  Therefore if the player wants to ‘look in bag’ it is a simple matter of using the LISTAT command to create a list of the objects stored in location 1 (the inside of the bag).  Just make sure that there are no connection listed in the connection table otherwise the player could find themselves inside the bag. . .!


Vocabulary
You now need to make sure you have entered all the words you will need ACE to recognise in the vocabulary table.  You will find this is the first file (called game1.txt).  It is very important to add as many synonyms (words that mean the same) as you can, for each word, because all game players are different and if, for instance, we have a collie dog in the game, some players would simply ‘examine dog’ while others would ‘examine collie’.  Also for speed of typing, some short commands can be entered as synonyms in the verbs, for example, x as well as exam and examine, and sr as well as search.  NOTE – all words that are synonyms must have the same identifying number as the original word.  As you get used to programming with ACE, you will develop your own way of doing things and can then keep a basic set of your own start files, set up just the way you like them.  It is only basic, ‘getting you started’ information which is included in the start files here.


Messages
Next you will want to enter some descriptive messages for your objects so that people can examine them while playing the game.  Don’t forget to check each of your locations as well.  People like to interact with everything in the game environment so you need to add descriptive messages for everything that could possibly be examined in a location, even if examining things doesn’t actually achieve anything within the game.  A prime example here is the ornamental pond.  A simple ‘examine pond’ command could get some descriptive message about being able to see goldfish in the water or something like that.  You could also add in messages to cover things like people wanting to paddle in the pond etc.  


You’d be surprised what people actually try and do within a game environment, so be as imaginative and flexible as possible.  Since the list of ‘examine’ commands tends to be the biggest within a game, it is usually easier to use a completely separate process table to contain all the ‘examine’ commands.  In our test game it will be process table 3,  which you will find in game5.txt


It might sound obvious, but try to keep things within the ‘examine’ process table, (or any of the others process tables for that matter), in alphabetical order.  You don’t have to, but the examine section can get very unwieldy and if you need to amend anything, it makes it much easier to find things.


Other programming entries
If you are going to have more than one entry for a particular thing (e.g. climbing) it is best to put all those entries into their own process table.  It makes it much easier if you want to add or amend things if you only have one process table to check.  In the example game you will see that ‘climb’ is in process table 6, with the initial entry in process table 0 which sends anything to do with climbing to look in process 6.


Another example of this would be put/place/insert for which there are several entries, and in the example game these are in process table 7.  As you check through process table 0 you will see that there have been several other process tables added to cover all sorts of things, which makes process 0 much easier to manage.


Process table 0
Each entry contains the word values of the verb and noun for the logical sentence (LS) they entry is to deal with, followed by any number of condacts.  When the player types in a command, if there is an entry in the table which matches the verb and noun1 of the LS then the condacts are performed, including sending the programme out to any process table that has been called within the condacts.


Process table 1
This is scanned by ACE after a location is described.  If you have used the system above whereby the locations are described in details within process 1 then this is where that description is picked up and printed on the screen.  It also allows any additional information which forms a part of any location (e.g. a door being either open or closed), to be displayed.


Process table 2
This table is scanned by ACE after every phrase extracted from the current LS.  In our example game, the entry dealing with the player spotting the bird on the bandstand and being scared off by the dog is in process to, enabling the game to check whether the player is at the bandstand, and whether the dog chasing the bird has already been done.


Process tables 3 onwards
Strictly speaking, ACE only requires the use of process tables 0-2 and 90% of the programming entries can go into process 0, but this makes for a terribly unwieldy piece of coding, which is why it is suggested that you set up process tables for specific things as explained above.  Note though, that if you set up a process table and then subsequently don’t use it, you must have a null entry of some sort in it, for example if you had a ‘look under’ instruction but  within your game you didn’t need to look under anything, you could set up a message like ‘you see nothing under there’ and place it in the relevant process table like this:


_        _        message (number)
                done


ACE doesn’t like compiling games where there are completely blank process tables, and it will cause an error during compiling.


Compiling your game
It couldn’t be easier!  Just open the file compiler.exe.  In the first box, browse to your first game file (in the example it is game.txt), highlight it and click open.  In the second box insert the name you want to use (in this case game.agd), highlight it and click open.  Make sure that the game directory path is specified in both boxes – it should read something like c:/Ace/game1.txt and c:/Ace/game.agd – or wherever you are saving your game files to.  If you are just testing the game, click the checkbox that says debugable (so you can use the debug feature while playing the game), and click compile.  If you are compiling for the final time and don’t want other people to be able to use the debugger then leave the box empty.  The compiler only takes a few seconds and if it comes across any errors it will stop and detail the error, which file it is in, and what line the error occurs in.  Couldn’t be simpler!


Once your game has compiled, you just need to open WinAce.exe, click file, open, and navigate your way to your compiled game file and away you go.